Alguns 'paradigmas' comumente divulgados na Internet são enganosos, literalmente FAKES. Veja alguns abaixo :
1 • Ninguém te paga um centavo para você programar mas sim para resolver problemas através da programação. Tenha em mente que ninguém tem interesse em saber o recurso que você utilizou para resolver o problema mas sim que o problema foi resolvido. Estão interessados nos fins e não nos meios. Dica : Quanto mais simples melhor isto se você quiser manter sua vida profissional saudável, por um longo período e próspera.
2 • Produtividade é muito mais importante ( e gera muito mais remuneração ) que inteligência. Já vi muita gente que tiro o chapéu mas o resultado do trabalho dele ficou uma ... Muitas vezes analisei, por exemplo, uma pesquisa e ela era tão grande e complexa que eu perguntei para o analista : Quantos computadores quânticos você precisa para rodar isso ?
3 • Não espere ajudando alguém ser recompensado. No máximo você será bem visto na empresa por mostrar cooperação com os outros funcionários. Existem equipes adversas e não deixe que isto afete seu serviço. Seja um funcionário agregador da equipe...é sinal de inteligência.
4 • Não confunda esforço com progresso. Muitas vezes a gente se mata para fazer uma porcaria. Se a coisa está difícil é porque você não pensou direito ou ainda não achou a melhor solução.
Portanto se você quer é um cara super-inteligente se preocupe em como aumentar sua produtividade e não como conhecer excepcionalmente bem uma ferramenta. As ferramentas mudam muito e conhecê-las muito bem não é tão significativo por causa dessas mudanças. Conheça o suficiente para executar sua tarefa com eficiência. Embora não tenha nada de errado em consultar o Google você irá perder muito tempo se sempre que tiver que fazer algo ficar consultando o Google.
Quanto a programação faça limpa e clara mas sem preciosismos. Na maioria das vezes ninguém vai ver o que você fez além de você mesmo mas um código bem feito, documentado (comentários, identado etc.) ajudará você a analisar o que você fez quando depois de um ano você pegar o mesmo código para manutenção.
Visando eficiência e produtividade podemos escolher entre 2 tipos de programação : Procedural e Orientada a objetos (OOP).
Dê cara respondo a pergunta : Qual a melhor? Resposta : Depende do projeto e elas são muito equivalentes, uma ganha num ponto e outra perde em outro.
Note bem que as linguagens se dão bem mais com um tipo de programação do que com outro. Por exemplo, C# se dá melhor com OOP e Visual Basic se dá melhor com a Procedural. Contudo, depende mais da solução a ser apresentada que da linguagem a ser utilizada.
Mais conhecida como programação estruturada consiste em 'fatiar' o trabalho a ser feito pelo sistema em diversas partes funcionais bem simples.
Por exemplo, entre milhares de atividades do site eu preciso autenticar um CNPJ. Posso fazer uma função para fazer isso e salvá-la numa biblioteca particular. Para chamá-la basta incluir o código dela num módulo ou classe quando for necessário.
Reutilização do Código : Uma vez feita e testada a rotina ela poderá ser agrupada numa biblioteca ou módulos de funcionalidades e utilizada futuramente em outros projetos. Digamos que precisaremos programar e testar apenas uma vez o código...uma boa vantagem sobre um novo código.
Divisão de tarefas complexas em processos extremamente simples : Toda tarefa pode ser dividida em partes até que se torne tão simples que não dê mais para dividir em outras rotinas. Então desenvolvemos essas rotinas pequenas e simples (como testar uma data, CPF, CNPJ etc.) e criamos outras rotinas agrupando essas rotinas mais simples da maneira que queremos e essa 'rotina mais complexa' que agrupa um conjunto de rotinas simples já executa uma tarefa do sistema, como a autenticação de um usuário no site.
Simplificação de processo : Se você tem uma função que valida a data você fabricaria outra função para verificar data ? Claro que não. E se você precisar chamar uma vez ou um milhão de vezes teria impacto na memória ou encavalaria o processamento? Não, o módulo é carregado apenas uma vez e se se for chamada um milhão de vezes o processo de controle colocaria todos eles numa fila e processaria um de cada vez. Não haveria uma 'cópia multipla' da funcionalidade na memória ou no sistema e este é um ponto importante sobre a vantagem sobre o programa tipo OOP. Digamos que só há uma 'instância' do código na memória para atender a todos.
Se fosse definir o objetivo da linguagem programação procedural diríamos que é a implementação de procedimentos. Se a gente já tem um monte de procedimentos pré-definidos em bibliotecas fica muito facil desenvolver sistemas com esta metodologia.
Infelizmente não há como separar o que o sistema precisa do que o que ele não precisa. Por exemplo, se fiz uma biblioteca com 10 funcionalidades e o sistema esta usando somente 2 ou eu removo as 8 não necessárias ou elas serão carregagas e processadas como parte do sistema. É um desperdício de memória e processamento mas dependendo do sistema é irrelevante. Por exemplo, ao inserirmos o bootstrap em nossos sites não temos como inserir só uma parte do mínimo, só o mínimo completo mesmo que a gente só use uma funcionalidade do bootstrap. Só que o bootstrap tem 50k de tamanho. O que isso impacta num site ou na frankia de transferencia de dados de um celular ? Praticamente nada.
OOP significa que tudo que o sistema tem que trabalhar no mundo real tem uma representação no sistema. Por exemplo, se preciso cadastrar clientes terei um objetos clientes no meu programa. Se tenho uma Nota Fiscal terei que ter um objeto NotaFiscal. Ai podemos criar relacionamentos que definem, por exemplo, que para inserir uma Nota Fiscal no sistema o cliente precisa estar cadastrado antes. E ai a complexidade vai subindo quanto mais 'entidades' ou 'objetos' temos em nosso sistema.
Como cada 'entidade' do mundo real tem seu 'objeto' no sistema que o representa fica bem intuitivo criar funcionalidades, propriedades, métodos, parâmetros para o objeto. Pura similaridade. Por exemplo, estou vendendo carros quais os parâmetros importantes que devo armazenar ? Marca, Modelo, Ano, Kilometragem. Fica fácil saber o que precisa ser feito porque temos um exemplo do mundo real.
Do mesmo jeito que na linguagem procedural podemos colocar nossas funcionalidades em 'bibliotecas de classe'
que agrupariam as funcionalidades do sistema. Ao precisar das funcionalidades de uma biblioteca basta incluir
ela no nosso sistema e instanciar seus objetos na memória pela palavra 'NEW'
Importante : A 'biblioteca de classes' seria a receita do bolo e a instanciação da mesma seria o bolo em sí,
ou seja, a 'biblioteca de classes' é um modelo e a instânciação é o objeto em sí.
Desperdício de memória e processador : Sempre que você utiliza o 'NEW' para instanciar uma classe você pede ao sistema que aloque memória, execute o módulo construtor, etc. Isto tem um custo. O problema é que se dois processos precisarem da mesma 'classe' você teria 2 cópias dos objetos na memória com o gasto de cpu e tudo mais. Se houver 3 processos que utilizem a mesma classe você teria 3 cópias do mesmo objeto. E se for recursivo? Aí daria nó no pingo d´agua.
A execução de uma aplicação orientada a objetos tende a ser mais lenta que a procedural ou estruturada porque envolve alocação de memória, execução dos métodos construtores sempre que a classe for instanciada.
O conceito de POO é bem mais complexo que o procedural além de muitas vezes ser necessário escrever mais código como os métodos getters e setters dos objetos.
Se fossemos definir um objetivo para OOP diríamos que POO define classes que virtualizam objetos contudo pelo 'método OOP' leva em conta os comportamentos ou métodos , parâmetros ou características dos objetos.
Tem analistas que se dão muito bem com o desenvolvimento procedura de sistema e outros com o desenvolvimento Orientado a Objetos (OOP). Sempre use o que você consegue obter maior produtividade.
Só não afirme que este é melhor e este é pior porque isso não existe e demonstraria falta de conhecimento sobre o assunto. Citando um exemplo, em sua opinião qual é a melhor base de dados : Oracle. MS SQL Server, MySQL ou Maria DB, Postgre ? Se responder que uma delas é a melhor está errado. Cada uma delas se dá melhor em um determinado cenário. Porque o Fusca vendeu mais que o Corola no Brasil ? Fusca é melhor que o Corola ? Não, porque foi mais adequado as necessidades brasileiras. E é sempre assim, se você pudesse andar com uma Ferrari porque anda com um Fiat Uno ? Porque é o que a sua realidade financeira é o que permite.
O tamanho da aplicação normalmente define qual a metodologia a ser usada. Se for meia dúzia de páginas utilize a procedural e se forem muitas páginas use a OOP mas isso é apenas um conselho, não uma regra.
Se a melhor ferramenta que você conhece é um martelo você tende a ver todos os seus problemas como pregos. Verdade seja dita tem gente que foi adestrada a desenvolver de uma maneira e só sabe desenvolver dessa maneira. É como o grande mestre da cozinha francesa que ao trocar a panela ele queima até o arroz. Isso revela muitas vezes incapacidade de adequação a situações novas.
Utilize a ferramenta de acordo com o que ela foi feita para desenvolver e não invente a roda porque o resultado sempre será péssimo. Peguei um sistema em VB6 (aplicação Desktop) que deveria migrar para web. O sistema só recebeu elogios de todos pela sua implementação.
Contudo sou um especialista e consigo ver a porcaria que fizeram. Conseguiram implementar OOP em um sistema desenvolvido em VB6. Falando a verdade, uma obra de arte a não ser pelo custo porque fizeram malabarismos para isso dar certo e o desenvolvimento ficou meio 'engessado' por esse 'modelo' de desenvolvimento.
Quanto a migração para web devido ao fato de usar OOP em uma linguagem que não é OOP deu nó em alguns pontos. Por exemplo, VB6 admite array de controles (o que é uma característica exclusiva de linguagens procedurais) enquanto VBNET e C# nem de longe permitem arrays de controles. Neste caso o jeito foi reescrever um monte de código por causa do devaneio dos analistas do projeto original.